fix(plugin-security): the sys_permission_set duplicate-name refusal carries UNIQUE_VIOLATION, and the packaged-set lock answers first - #19437

…ter (objectstack-ai#19471)

Fixes objectstack-ai#18571

Clause-②: yes (widening)

Implemented-by: `claude/issue-18571-unowned-refusal-counter`

## What was wrong

The permission-set seeder's unowned refusal moved no counter, while
every sibling refusal on both seeder axes moved one.

`bootstrap-declared-permissions.ts` `upsertPackagePermissionSet` refuses
to materialize a declared set whose owner cannot be resolved
(`!packageId`): an unowned `managed_by:'package'` row makes uninstall
undefined, which is the ADR-0086 D3 ambiguity the branch exists to
prevent. objectstack-ai#18564 gave that refusal an author-visible line. What it left
behind is the programmatic half — the branch returned an outcome with
all six counters at `0`, so a caller that reads no log at all (a boot
report, a Setup surface, a test) could not tell a pass that refused a
declaration from a pass with nothing to do. The branch's own comment
said so verbatim: 「this branch moves no counter either, so the outcome
said nothing about it」.

The asymmetry is measured, not cited. The sibling axis
(`bootstrap-declared-capabilities.ts`) has carried `skippedUnowned`
since objectstack-ai#4967 and increments it at the same ADR-0086 D3 boundary.

Re-verified on `origin/main` before writing, against the three commits
that landed on this file pair after the card was filed — `cf39b83c`
(objectstack-ai#18564), `f9e16d85` (objectstack-ai#19411), `8f6d8314` (objectstack-ai#19437). None of them changed
the picture; the defect was live at `fbc12be3`.

## What changed

`PermissionSeedOutcome` gains a **required** `skippedUnowned: number`,
incremented on the `!packageId` branch.

Required, like `skippedForeign` and unlike the optional `deleted`: an
absent key on a *refusal* count reads exactly like a pass with nothing
to refuse, which is the defect restated.

Four construction sites, all in-repo, all initialized:

| site | before | after |
|:---|:---|:---|
| `bootstrap-declared-permissions.ts:232` (`upsertPackagePermissionSet`)
| `{ seeded, updated, unchanged, unreadable, skippedEnvAuthored,
skippedForeign }` | `+ skippedUnowned: 0` |
| `bootstrap-declared-permissions.ts:377`
(`bootstrapDeclaredPermissions`) | same six | `+ skippedUnowned: 0` |
| `permission-set-projection.ts:569` (`upsertEnvPermissionSet`) | same
six | `+ skippedUnowned: 0` |
| `permission-set-projection.ts:752` (`retirePermissionSetRecord`) |
same six `+ deleted: 0` | `+ skippedUnowned: 0` |

The boot aggregator forwards it alongside the five counters it already
carried. The branch's stale comment — the one that stated the defect —
is corrected rather than left lying.

⛔ **The refusal itself is unchanged**, and no other diagnostic, log line
or field was added. This adds a channel, not a verdict.

## Tests

Four cases in `bootstrap-declared-permissions.test.ts`, modelled on the
capability axis' instrument:

- `BOOT-LOOP DOOR: an unowned declaration increments skippedUnowned` —
and lands in its own counter, with `skippedForeign` /
`skippedEnvAuthored` / `unreadable` all still `0`.
- `PUBLISH DOOR (ADR-0086 P2): the materializer increments it too` —
that caller passes no collector and aggregates nothing, so a fix wired
into the boot loop alone would have left it exactly as silent as before.
Testing one door is testing half.
- `CONTROL: a pass that refuses nothing leaves it at 0 through both
doors` — the discriminating half; without it a counter incremented on
every declaration satisfies both assertions above.
- `⭐ CONSERVATION: every named declaration lands in exactly one counter`
— six declarations, one per counter, summed over **every** counter the
outcome declares rather than a hand-picked subset, so a future counter
with no home here fails this pin instead of hiding. That is the failure
mode `skippedUnowned` itself was.

No existing assertion was weakened or deleted, and none broke: the
outcome is read with `toMatchObject` and per-field `expect` throughout,
never `toEqual` / `toStrictEqual`.

## The fence this round was told to stop at, and why it did not

Triage attached a stop condition verbatim:
「承接席若发现该类型是跨包公开导出且有外部消费者,那一刻回来找维护者,⛔ 不自行扩面」.

The first half is true — `PermissionSeedOutcome` is barrel-exported at
`index.ts:125` and re-exported at
`bootstrap-declared-permissions.ts:85`. So the second half was measured:
**does anything CONSTRUCT one outside
`packages/plugins/plugin-security/`?** Reading one is harmless;
constructing one is what a required field breaks.

- **This repo, whole-tree sweep:** every occurrence of the type name and
of the distinctive member `skippedEnvAuthored` is inside
`packages/plugins/plugin-security/`. The only cross-file consumer,
`security-plugin.ts:3759`, *reads* `r.skippedEnvAuthored` — no
construction. No other in-repo package re-exports the type.
- **`objectui` (pinned sibling):** no dependency on
`@objectstack/plugin-security`, and no occurrence of the type. Its hits
are prose about the plugin's FLS middleware.
- **Downstream app repos checked out here (`duly`, `hotcrm`,
`objectos`):** only `hotcrm` depends on the package (`17.4.0`); it
imports `SecurityPlugin`, `PermissionEvaluator`,
`appDefaultPermissionSetName` and `buildContextForUser` in six tests and
never names the outcome type. `duly` and `objectos` do not depend on it
at all.

Zero external constructors found on every surface reachable from here,
so the field is required as the card and triage both asked. The residual
is named rather than papered over: the package publishes to npm, so an
unreachable consumer cannot be excluded by a sweep — what can be said is
that nothing in any checkout available to this round constructs one.

## Acceptance notes

Noted, not filed:

- `security-plugin.ts:3754-3761` picks the publish materializer's
failure reason by elimination: `skippedForeign`, else
`skippedEnvAuthored`, else the unowned wording as the fallback arm. With
`skippedUnowned` now on the outcome that last arm could name its own
counter instead of being reached by exhaustion. Behaviour is identical
either way and the current wording is correct, so this is a legibility
preference, not a defect — and the card's fence says a channel, nothing
else. Carrier: the next PR that touches this publish branch.
- `permission-set-projection.ts` documents the permission-set accounting
identity only in the new member's docblock, while the capability axis
states its identity on `materializedNames`. Both are correct and neither
is wrong; consolidating them is a prose-shape preference, not a defect.
Carrier: none — no PR or person is queued to touch this docblock.

## Local verification

See the dev report comment on objectstack-ai#18571 for the gate families, their exit
codes and the `check-widening-tells` invocation.

---
_Generated by [Claude
Code](https://claude.ai/code/session_01HnRAeVTLJevtQ5iCPX6JSm)_

---------

Co-authored-by: Claude <noreply@anthropic.com>

…wn ledger key (objectstack-ai#19782)

Fixes objectstack-ai#19441

Clause-②: yes

## What changed

Two halves, in two packages, landed together (the triage rider: the
registration and the comment are not interchangeable).

1. **`packages/spec` ledger** —
`ERROR_CODE_LEDGER['@objectstack/plugin-security']` gains three
provenance rows, `INVALID_STATE`, `NOT_FOUND`, `NOT_OVERRIDABLE`, each
with a comment naming the throwing class, its status and its door. They
cover all four emission points the card listed (`NOT_OVERRIDABLE` is
stamped by two classes, one row). Every code was already registered
under another package (`@objectstack/rest`,
`@objectstack/metadata-protocol`), so the `ErrorCode` union and the wire
are unchanged: provenance, not identity. The `NOT_FOUND` entry in
`STANDARD_SYNONYM_WAIVERS` keeps its `code`/`shadows`; its `reason` text
now names plugin-security among the emitters (the same edit the
`FORBIDDEN` waiver got when cloud-connection joined).
2. **`plugin-security`** — the `PackagedPermissionSetLockedError`
docblock no longer says "the code is a StandardErrorCode, so no ledger
entry is minted". It now says what is true: `NOT_OVERRIDABLE` is a
registered extension code, NOT a `StandardErrorCode` member, and this
package's own owner key lists it. The two overlay-discard error classes
get a one-line pointer to their rows. The plugin-security edits are
comments only.

## Premise check (on `origin/main` `041c8cf6`)

- The four stamps are at `packaged-permission-set-lock.ts:266`, `:287`
and `permission-set-overlay-discard.ts:91`, `:101`, all spelled
`readonly code = '...'`.
- All four are live. `assertPermissionSetNotPackageDeclared` is called
from `permission-set-projection.ts` (three sites) and
`packaged-permission-set-lock-gate.ts`. `discardPermissionSetOverlay` is
registered by `security-plugin.ts` and served by rest's `POST
.../security/permission-sets/:id/discard-overlay`. The classes are
exported from `index.ts`.
- They ship: after the build, each of the three literals hits 1 file in
`packages/plugins/plugin-security/dist/*.js` (control
`UNIQUE_VIOLATION`: 1).
- None of the three was listed under plugin-security before this PR.
- `check:error-code-provenance` declares class fields out of its scan
(see its header, "BLIND ... and a class field"), so it was green before
this PR and is still green now (exit 0).

## Tests

- New pin in `error-code-ledger.test.ts`: `lists the plugin-security
class-field stamps under their stamping package`. It checks each code is
listed under plugin-security AND is still listed under its first owner,
and that it parses as an `ErrorCode`. It also checks `NOT_OVERRIDABLE`
is absent from `StandardErrorCode.options`, with a lit control:
`PERMISSION_DENIED` is present.
- `pnpm --filter @objectstack/spec exec vitest run --maxWorkers=2
src/api/error-code-ledger.test.ts`: 21 passed.
- `src/api` (44 files): 1518 passed.
- plugin-security `packaged-permission-set-lock*.test.ts` and
`permission-set-overlay-discard.test.ts` (3 files): 33 passed.
- `typecheck` for `@objectstack/spec` (including scripts-typecheck and
test-typecheck) and for `@objectstack/plugin-security`: exit 0.
- **Ablation** (one-off, not left in the tree): I deleted the
plugin-security `NOT_OVERRIDABLE` row with
`scripts/ablation-replace.mjs` (anchor x1 -> x0, marker x0 -> x1) and
ran the pin: `1 failed | 20 passed`, failing with `NOT_OVERRIDABLE
listed under plugin-security: expected [ 'INVALID_METADATA', ...(5) ] to
include 'NOT_OVERRIDABLE'`. After the restore the blob equals HEAD
(`d8ad7285`) and `git diff HEAD` is empty. The suite imports the ledger
from `src`, so no dist rebuild was involved. My first attempt was a
no-op: the replacement text was already inside the anchor, so the tool
refused and restored. It is not counted.

## Gates (head `5a1a2efd`)

`dispatch-gates.mjs --commands` listed 89 commands; `--ran` reconciled
all of them (86 run, 3 NOT MEASURED, 0 unrun). All 86 that ran exited 0,
including `check:error-code-provenance`,
`check:dispatcher-error-vocabulary`, `check:error-code-casing`,
`check:api-surface`, `check:docs`, `check:authorable-surface`,
`check:adr-0087-registration`, `check-changeset-no-major` and
`check:nul-bytes`.
NOT MEASURED, each exit 3 PREREQUISITE (they need a whole-workspace
build that was not done locally; left to CI):
`check:dual-build-cjs-loads`, `check:i18n`, `check:type-check-debt`.
`pnpm lint` (a repo-wide scan) was not run locally; that is CI's run.

## Changeset level

The dispatch suggested `patch`. The changeset grades `@objectstack/spec`
**minor** instead: AGENTS.md's Post-Task Checklist says `Clause-②: yes`
takes at least `minor`, `check-changeset-no-major.mjs`'s level axis
enforces that, and the ledger header says registering a code widens the
published face. The precedent is objectstack-ai#19437 (the prior plugin-security
ledger row: spec minor). plugin-security has no changeset entry because
its diff is comments only.

## Acceptance notes

- The card's other idea, making `check:error-code-provenance` see
class-field spellings, is **not** done here. That is a gate-population
change and a separate decision. Measurement for it: these four stamps
were invisible to the gate because class fields are out of its scan. The
new vitest pin holds only these rows; a future class-field stamp in any
package would still be invisible to the gate.

---
_Generated by [Claude
Code](https://claude.ai/code/session_01VWsFyWDp8Rjb2Ma6a3Cyo8)_

Co-authored-by: Claude <noreply@anthropic.com>